Webpack 빌드 속도 최적화

2021-04-09

현재 다니는 회사를 반년 넘게 다니며 느낀 가장 불편한점 한가지는 프로젝트 빌드 속도가 너무 느리다는 점이었다. 회사 프로젝트는 번들러로 Webpack을 사용하고 있었는데, 번들이 정해진 라우팅 별로 쪼개져있다는 점을 빼고는 특별한 부분이 없었다. Webpack 자체가 다른 번들러에 비해 느린 것도 있지만 대체 왜 이렇게 느린건지 분석하고 개선할 수 있으면 개선해보기로 했다.

우선 Webpack 빌드 개선 방법과 사례를 찾아보았다.

Webpack 공식 문서

https://webpack.js.org/guides/build-performance/

웹팩 공식 문서에서 개발시 빌드 성능을 개선하기 위해 권장하는 방법은 다음과 같다:

• 가능하면 최신 버전의 웹팩을 사용하기
• 로더를 필요한 디렉토리에서만 사용하기
• 빌드 결과물 크기를 줄이기
  • 라이브러리 의존을 줄인다.
  • chunk를 잘 나눈 뒤 비동기 처리한다.
  • 안쓰이는 코드를 제거한다.
  • 변경된 부분만 컴파일한다.
• 메모리에 올려 컴파일하기 (Hot Module Reloading)
• 적절한 Devtool(소스맵) 사용하기
• TypeScript를 쓰는 경우 타입 체킹은 ForkTsCheckerWebpackPlugin이용하기.

Slack 블로그의 Webpack 빌드 개선 글

https://slack.engineering/keep-webpack-fast-a-field-guide-for-better-build-performance/

Slack팀에서 시도한 빌드 성능 개선 방법은 다음과 같다. 참고로 Slack은 프로덕션 빌드를 매우 자주 내보내기 때문에 프로덕션 빌드 성능을 개선하는 것에 초점을 맞추고 있다:

• 병렬 처리
  • parallel-webpack을 이용하여 병렬로 빌드 실행
  • happypack을 이용하여 병렬로 loader 실행
  • UglifyJSPlugin의 parallel option사용
• 계산 부하 줄이기
  • Minification을 최소화하기
• 똑같은 코드가 여러번 import되지 않게 하기
  • webpack Bundle Analyzer 과 Bundle Buddy을 이용하여 중복되는 부분을 찾고 CommonsChunkPlugin를 이용하여 chunk를 공유하도록 쪼갠다
• 다른 파일을 참조하는 경우가 없는 파일은 파싱에서 아예 제외시키기
• autodll-webpack-plugin을 이용하여 한번 빌드된 번들을 재사용하도록 하기.
• 적절한 소스맵 사용하기
• 빌드 캐시 사용하기
  • cache-loader
  • babel-loader을 사용하는 경우 built-in caching
• 빌드하는 하드웨어의 성능에 투자하기

Box라는 회사의 블로그 글과 survivejs라는 곳에도 비슷한 내용이 담겨있었다.

적용

우선 성능 개선을 제대로 측정하기 위해 SpeedMeasureWebpackPlugin을 이용하였다.

개선 전 프로젝트 최초 빌드 시간은 약 3분 30초 가량 소요되었고, watch 상태에서 코드 3줄을 바꾸고 재빌드시 10초 가량 소요되었다. 가장 시간이 많이 소요되는 부분은 sass-loader였다. 이 부분에 대해 찾아보니 sass를 사용하지 말라는 글도 있었고, fast-sass-loader와 같은 다른 종류의 sass-loader도 발견했지만 개발시 사용하기에 적절하지는 않아서 적용하지는 않았다. 그리고 사용하기에 현재 프로젝트의 sass 구조에도 맞지 않았다. 실질적인 개선을 하려면 프로젝트 전체에 걸쳐 sass파일의 구조를 바꿔야함이 분명해서 이 부분은 포기했다. 대신 빠르게 당장 적용할 수 있는 부분을 찾았다.

기존 프로젝트의 Webpack 설정은 Devtool로 기본 설정인 'source-map'을 사용하고 있었다. 'source-map' 설정은 원본 소스를 보여주기 때문에 개발시에 용이한 것은 맞지만 빌드 속도와 watch 상태에서의 재빌드 속도 모두 매우 느리기 때문에, 빠른 빌드 시간이 더 중요한 경우 좀 더 계산이 저렴한 Devtool을 쓰는게 맞다고 판단했다.

그래서 공식 홈페이지에서 추천하는 설정인 'eval-cheap-module-source-map'을 사용하는 빌드 스크립트를 추가했다. Devtool 바꾼 뒤 최초 빌드시간은 크게 차이가 나지 않았다. 그러나 watch 시 재빌드 시간은 0.3초로 매우 빨라진 것을 확인했다. 그리고 source-map옵션이 아니라 원본 소스가 그대로 보여지지는 않지만 개발자도구에서 디코딩된 형태로 코드가 보여지기 때문에 line by line 디버깅이 가능했다. 얻는 성능에 비해 원본 소스가 그대로 보여지지 않는 것은 별로 큰 trade-off가 아니었기 때문에 무조건 'eval-cheap-module-source-map'을 이용하는 것이 개발 효율에 좋을 것이라 판단하였다.

'babel-loader?cacheDirectory'을 사용하면 babel의 캐싱을 이용할 수 있다. 완전 최초 빌드는 여전히 오래 걸리지만 babel-loader가 처리한 부분을 캐싱해놓기 때문에 재빌드 시간이 꽤 단축된다. 브랜치를 바꾸거나 할 때 빌드 결과가 캐시로 남아있어서 다시 빌드를 돌리더라도 이전만큼 오래 걸리지 않는다. 캐시를 켰을 때 빌드시간은 약 32초 가량 걸렸다. 캐시 설정을 주지 않았을 때 3분 30초 였던 것을 생각하면 장족의 발전이다.

이외에도 분석하고 시도해볼 수 있는 것은 많았지만(예를 들어 속도가 느린 babel-loader자체를 바꾼다거나...), 가성비가 좋지 않다고 판단하여 잠깐 시도하다 그만두었다. 설정 일부를 바꾸는 것만으로도 빌드 시간을 많이 줄일 수 있었다.

2021-11-20

연관 링크 추가

🔗 Understanding why our build got 15x slower with Webpack 5